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ABSTRACT 

Information  Technology  Division  was  tasked  by  the  Headquarters  Australian  Defence 
Force  to  develop  tools,  through  modelling  and  simulation,  for  effectiveness  studies  of 
Command,  Control,  Commurucation  and  Intelligence  (C3I)  systems.  Such  tools 
needed  to  aUow  for  the  study  of  systems  at  the  strategic,  operational  and  tactical 
levels,  including  aU  services  and  joint  forces.  The  primary  tool  developed  is  the 
Distributed  Interactive  C3I  Effectiveness  (DICE)  simulation  in  which  human  players 
are  complemented  by  artificial  agents.  The  DICE  simulation  environment  can  be 
connected  to  lower  level  battlefield  simulations  and  war  games  which  are  used  to 
represent  the  overaU  military  mission,  operation  or  battle.  The  impact  of  C3I  aspects 
on  the  overall  mission  can  be  used  to  gauge  C3I  system  effectiveness.  What  is  termed 
Phase  1  of  development  has  been  completed  and  is  reported  collectively  through  a 
number  of  detailed  documents.  This  report  gives  a  substantial  overview  of  the 
simulation  capabiUty  along  with  areas  of  future  research  and  development. 
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The  Distributed  Interactive  C3I  Effectiveness 

(DICE)  Simulation 


Executive  Summary 

Information  Technology  Division  was  tasked  by  the  Headquarters  Australian  Defence 
Force  to  develop  tools,  through  modelling  and  simulation,  for  effectiveness  studies  of 
Command,  Control,  Communication  and  Intelligence  (C3 1)  systems.  Such  tools 
needed  to  be  general-purpose  to  allow  for  the  study  of  systems  at  the  strategic, 
operational  and  tactical  levels,  including  all  services  and  joint  forces.  The  primary  tool 
developed  is  the  Distributed  Interactive  C3I  Effectiveness  (DICE)  simulation  for  which 
Phase  1  of  development  has  been  completed.  This  report  gives  a  substantial  overview 
of  the  simulation  capability  along  with  areas  of  future  research  and  development.  The 
simulation  has  the  following  key  features; 

•  The  abiUty  to  graphically  define  the  network  of  nodes  and  links  that  form  the 
central  C3I  system  under  examination. 

•  The  ability  to  represent  communication  over  network  links  through  stochastic 
or  deterministic  time  delays. 

•  The  abiUty  to  specify  a  scenario  under  which  the  C3I  network  will  be  exercised. 

•  The  ability  to  artificiaUy  represent  and  emulate  over  time  the  functionality 
(input,  output  and  internal  activities)  of  network  nodes  through  the  use  of 
artificial  agents. 

•  The  ability  (optional)  to  assign  human  players  to  represent  the  actions  of 
network  nodes.  A  standard  language  is  needed  for  communication  between 
human  players  and  artificial  agents;  ADF  and  DICE-specific  Australian 
Defence  Formatted  Messages  (ADFORM)  are  used.  A  variety  of  ADFORM- 
related  software  has  been  developed  including  a  graphical  user  interface  (GUI) 
facUity  permitting  human  players  to  receive,  create  and  submit  ADFORM 
messages. 

•  The  ability  to  define  appropriate  measures-of-merit  (MOM)  to  be  used  in  a 
particular  study  and  to  develop  artificial  agents  for  the  computation  of  those 
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measures  during  run  time.  The  ability  to  specify  mission  requirements  for  each 
measure. 

•  Simulation  controller  facilities  for  run-time  monitoring  and  control. 

•  A  simulation  kernel  that  allows  interoperation  of  autonomous  artificial  agents, 
human  player  facihties,  controller  facilities  and  PUI  for  interfacing  to  battle 
simulations  and  CSS,  for  example.  A  single  and  multiple  execution  capability 
exists  as  well  as  flexible  execution  rate. 

•  A  core  relational  database  architecture. 

•  Post-simulation  analysis  facihties  allowing  inspection  of  single  and  multiple 
simulation  execution  data.  Features  include  the  inspection  of  information  flows 
and  general  effectiveness  analysis  through  comparison  of  MOM  values  against 
mission  requirements. 

•  An  interface  that  allows  interoperation  of  the  DICE  simulation  with  an  in- 
house  developed  air  defence  simulation  ADSIM.  Interfacing  to  tactical 
battlefield  simulations  and  war  games  permits  inspection  of  the  impact  of  C3I 
aspects  on  the  overall  mihtary  mission  in  order  to  gauge  C3I  system 
effectiveness. 

•  A  partially-developed  interface  that  will  lead  to  full  compliance  with 
Distributed  Interactive  Simulation  (DIS)  protocols. 

In  addition  to  the  DICE  simulation,  a  Petri  net  explanation  and  analysis  capabihty 
and  GUI  environment  for  conveying  the  underlying  characteristics  of  a  Petri  net  agent 
to  a  military  domain  expert  was  developed. 

Simulation  is  a  burgeoning  technology  within  the  Defence  community.  In  particular, 
in  the  area  of  C3I,  the  interoperation  of  simulated  and  real  systems  is  regarded  as  a 
key  requirement  for  mission  rehearsal  and  other  forms  of  training  that  also  fachitate 
subsequent  analysis.  A  follow-on  task  wiU  address  the  following  areas: 

•  The  provision  of  simulation  technology  to  the  Defence  organisation; 

•  Further  development  or  acquisition  of  tools  for  C3I  analysis; 

•  Applications  to  Defence  studies; 

•  Interfacing  simulation  with  operational  C3I  systems;  and 

•  General  measure  of  effectiveness  and  analysis  R&D. 

Experiences  and  capabihties  gained  from  the  above  ventures,  along  with  research  in 
the  fields  of  artificial  intelligence,  DIS  and  performance  optimisation,  will  significantly 
influence  future  development  of  the  DICE  simulation. 
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ADF 

Australian  Defence  Force 

ADFORM 

Australian  Defence  Formatted  Message(s) 

ADFORMS 

Australian  Defence  Formatted  Message  System 

ADSIM 

Air  Defence  Simulation 
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Airborne  Early  Warning  and  Control 
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Distributed  Interactive  Simulation 

DSDME 

DICE  Simulation  Development  and  Management  Environment 
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1.  Introduction 

As  stressed  in  the  Australian  Defence  White  Paper  of  1994[1],  effective 
Command,  Control,  Communication  and  Intelligence  (C31)  of  Australia's  forces 
is  fundamental  to  the  successful  conduct  of  Australian  Defence  Force  (ADF) 
operations,  in  any  conflict  or  peacetime  activity.  Accordingly,  there  is  a  drive  to 
identify  and  remedy  the  weaknesses  of  existing  C31  systems  and  to  specify  and 
work  towards  goal  architectures  for  the  future.  Having  the  ability  to  study  the 
effectiveness  of  existing  and  future  military  C31  systems  is  essential  to  this 
process.  Information  Technology  Division  (ITD)  was  tasked  to  develop 
modelling  and  simulation  tools  to  enable  such  studies  to  be  conducted. 

A  typical  C31  system  structure  for  the  defence  of  Australia  might  involve 
elements  of  the  three  services  and  accommodate  conflict  at  all  levels.  The 
strategic  level  embraces  the  higher  echelons  of  the  military  and  political 
orgamsations  concerned  and  hence  addressing  this  level  requires  addressing 
decision-making  at  lower  (operational  and  tactical)  levels  also.  The  C31 
architecture  can  be  pictured  as  a  complex  network  of  nodes  and  links.  The  nodes 
are  typically  centres  of  decision  making;  information  processing  or  filtering; 
mformation  transfer;  or  combinations  of  these.  The  liidcs  are  the  inter-node 
communication  channels  that  transmit  many  forms  of  information.  In  a  time  of 
conflict,  the  C31  system  might  be  stimulated  by  intelligence  concerning  the 
detection  of  potentially  hostile  enemy  activity.  This  would  consequently  cause 
the  generation  and  passage  of  internal  information  that  might  result  in  changes 
in  readiness  and  maybe  the  deployment  of  reaction  forces.  To  study  the 
effectiveness  of  military  C31  systems  requires  analysis  of  the  impact  of  C31 
procedures  and  technologies  on  the  overall  military  mission  concerned.  The  term 
mission  is  used  here  to  describe,  for  example,  an  operation,  battle  or  exercise  for 
which  there  exists  one  or  more  military  objectives  that  need  to  be  attained, 

The  requirement  on  ITD  was  not  to  develop  tools  specific  to  any  particular 
military  service  or  level  of  conflict,  but  rather  to  create  a  general  purpose  suite  of 
tools,  specific  instances  of  which  could  be  used  to  address  any  particular  study 
at  hand.  It  was  decided  that  the  main  means  of  achieving  this  suite  of  tools  and 
the  associated  skill  base  would  be  through  the  process  of  developing  an 
interactive  simulation  with  some  capability  for  remote  participation.  The  goal 
tool  is  known  as  the  Distributed  Interactive  C31  Effectiveness  (DICE)  simulation. 

Research  and  development  of  the  DICE  simulation  and  associated  tools  was 
initially  conducted  under  the  DGFD(Joint)-sponsored  C31  Simulation  Studies 
task  ADF  93/237.  At  the  completion  of  this  task,  the  simulation  was  developed 
to  a  significant  stage,  referred  to  as  Phase  1,  upon  which  future  developments 
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will  build.  This  document  reports  the  general  aims  and  features  of  this  Phase  1 
capability  along  with  areas  of  future  research  and  development. 


2.  General  Requirements  and  Features  of  the 

DICE  Simulation 

2.1  Interactive  capability 

It  was  identified  that  the  nucleus  of  any  software  tools  developed  tmder  this  task 
should  be  an  interactive  simulation  with  some  distributive  capability  that 
enables  participation  by  a  number  of  possibly  remotely  located  human  players. 
The  interactive  nature  must  allow  the  decision-making  practices  of  real 
commanders  to  be  injected  and  accommodated  in  a  adequately  realistic  manner. 
For  this  reason,  access  to  real-world  or  trial  command  support  systems  (CSS)  by 
the  human  players  is  a  desirable  option. 

2.2  Artificial  agents 

The  human  players  need  to  be  complemented  by  a  number  of  artificial  ones 
(artificial  agents)  in  a  manner  whereby  the  two  types  can  communicate.  The 
artificial  agents  need  to  be  modular  in  construction  and  adequately  realistic 
representations  of  the  real-world  entities  that  they  emulate.  Artificial  agents 
might  represent  individual,  or  groups  of,  commanders  in  a  C31  system  or  an 
aggregated  representation  of  some  C3I  sub-system  or  entity.  The  underlying 
assumptions  and  characteristics  of  these  agents  need  to  be  clearly  conveyable  to 
a  military  domain  expert. 

2.3  Application  development  environment 

An  application  development  capability  that  includes  scenario  generation  is 
required  that  can  be  easily  employed  by  analyst-assisted  military  personnel.  A 
typical  application  can  be  regarded  as  centred  about  a  complex  set  of  nodes  and 
links  that  represents  the  central  C3I  network  under  study.  The  real  and  artificial 
players  would  generally  form  the  nodes  of  this  central  network  that  is  exercised 
by  some  specified  scenario.  The  central  network  is  surrounded  by  an  external 
environment  that  encompasses  any  aspects  that  are  not  explicitly  represented  in 
the  central  network  but  which,  nevertheless,  form  important  contributions  to  the 
scenario  being  addressed.  What  lies  outside  the  central  network  and  what  lies 
within  depends  on  the  depth  and  breadth  of  the  scenario  being  simulated.  The 
external  environment  embraces  such  aspects  as  enemy  activity,  battlefield 
information,  and  sensor  information  which  might  be  represented  by  individual 
models,  simulations  or  simple  look-up  tables.  The  external  environment  can  be 
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considered  to  inject  stimuli  into  the  central  network  and  be  influenced  by  the 
actions  that  eventuate  from  that  network. 

2.4  Communications 

In  real  C3I  systems,  commumcations  between  nodes  can  take  many  forms 
including  formatted  and  unformatted  messages;  tables  of  data;  graphical 
displays;  and  video  images.  In  the  DICE  simulation,  a  standard  form  of 
commumcation  is  required  to  reduce  information  ambiguity  and  facilitate 
information  exchange  between  both  human  and  artificial  players. 
Communication  between  the  central  network  and  the  external  environment  also 
needs  to  be  achieved  through  the  use  of  this  standard.  A  language  based  on 
formatted  textual  messages  is  required;  such  messages  can  either  bear  a  direct 
resemblance  to  a  military  message,  or  accompany  or  summarise  information  of  a 
different  form.  Having  a  standard  language,  understandable  to  both  humans 
and  machines,  for  information  exchange  is  also  a  major  requirement  in 
command  and  control  systems  of  the  ADF.  The  Australian  Defence  FORmatted 
Message  System  (ADFORMS)[2]  is  the  agreed  standard  for  the  ADF  and  this 
standard  has  been  chosen  as  a  foundation  in  the  DICE  project[15]. 

2.5  Tactical  environment 

Interfaces  to  tactical  level  models  and  simulations  that  represent  the  external 
environment  are  essential.  This  capability  permits  the  impact  of  the  represented 
C3I  system  on  the  military  mission  concerned  to  be  determined  and  hence  allow 
evaluation  of  the  system  s  effectiveness.  Such  models  and  simulations  may  be 
themselves  remotely  located  and  hence  the  ability  to  interoperate  in  a  distributed 
environment  is  again  important. 

2.6  Modes  of  execution 

For  flexibility,  the  simulation  needs  to  be  capable  of  running  in  interactive  and 
non-interactive  modes  and  have  variable  execution  rate  allowing  real-time  and 
non  real-time  execution.  A  multiple  execution  capability  for  parameter 
sensitivity  study  and  Monte  Carlo  type  analysis  is  another  important 
requirement. 

2.7  Analysis  capabilities 

An  extensive  analysis  capability  is  required  to  allow  effectiveness  evaluation  to 
be  conducted;  this  might  include  a  replay  facility  and  history  and  review 
capability. 

References  13  and  14  report  a  method  of  comparing  C3I  system  measures  of 
performance  (MOP)  with  mission  requirements  in  order  to  determine  the 
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effectiveness  of  a  C3I  system.  The  method  is  based  on  the  premise  that  the 
effectiveness  of  a  C3I  system  is  to  what  extent  that  system  satisfies  the  mission 
requirements  of  that  system.  The  philosophy  of  the  DICE  simulation  project  is 
that  the  effectiveness  of  C3I  would  be  evaluated  by  inspecting  its  impact  on  the 
overall  military  mission  being  addressed.  The  work  of  references  13  and  14 
accommodates  the  question  how  much  impact  is  good  enough? ".  The  terms 
performance  and  effectiveness  will  be  adopted  temporarily. 

The  following  stages  can  be  considered  in  determining  the  effectiveness  of  C3I 
systems,  namely  (the  word  system'  is  used  quite  loosely  here): 

(i)  Decide  what  is  and  what  is  not  the  C3I  system  to  be  examined;  determine 
the  boundaries  of  the  system; 

(ii)  Determine  suitable  MOP  for  the  C3I  system  which  are  independent  of, 
and  hence  will  not  be  influenced  by,  events  outside  the  boimdaries  of  that 
system  (multiple  MOP  may  be  required); 

(iii)  Determine  mission  requirements  in  terms  of  the  system  MOP; 

(iv)  Compare  system  performance  against  mission  requirements  to  determine 
overall  effectiveness. 

In  references  13  and  14,  system  MOP  and  mission  requirements  are  expressed 
as  continuous  functions  of  independent  parameters  that  are  modelled  or 
analysed  independently  but  in  a  common  context.  Given  these  functions,  the 
extent  to  which  the  mission  requirements  are  met  is  determined  through 
n-dimensional  geometric  integration  applied  to  the  system  MOP  and  the  mission 
requirements  locus.  The  authors  state  that  simulation  may  be  one  means  of 
determining  the  continuous  functions  concerned.  However,  if  the  study  matter  is 
complex  then  such  functions  may  be  actually  statistical  in  nature  and  hence 
difficult  to  represent  in  an  analytical  or  continuous  manner.  One  means  of 
addressing  such  a  case  is  to  evaluate  the  overall  effectiveness  by  comparable 
statistical  means,  this  would  require  knowledge  of  the  exact  statistical  nature  of 
the  system.  Another  method  of  addressing  this  problem  is  through  multiple 
executions  (eg  for  Monte  Carlo  purposes)  of  a  simulation  of  the  system  under 
examination. 

This  approach  was  considered  useful,  to  adopt  it  required  establishing 
particular  but  more  general-purpose  capabilities.  Stages  (i)  to  (iii)  above  can  be 
problematical  steps  in  system  analysis  and  the  DICE  simulation  would  not  be 
expected  to  solve  such  problems  although  its  application  may  result  in  a  better 
understanding  of  the  problem  domain.  A  general  facility  for  specification  of 
system  measures  and  mission  requirements  (optional)  against  those  measures 
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was  required.  The  simulation  itself  would  be  associated  with  the  actual 
implementation  of  Stage  (iv). 

The  overall  characteristics  of  the  DICE  simulation  are  summarised  in  Figure  1 
which  is  essentiaUy  a  breakdown  of  the  functional  areas  of  the  DICE  simulation 
environment.  Indicated  by  the  uppermost  row  of  this  figure  are  the  players  in  the 
simulation,  namely  the  simulation  controller  or  analyst;  artificial  agents;  and 
human  players.  Peripheral  units  (PU)  in  the  DICE  environment  include  any  war 
games  and  battle  simulations  etc.  that  may  be  employed  to  represent  tactical 
aspects,  plus  CSS  that  may  be  required  by  the  human  players.  Players  plus  PU 
are  considered  the  nodes  in  the  overall  DICE  simulation,  ie  the  central  network 
plus  the  external  environment.  The  simulation  kernel  is  the  central  engine  of  the 
simulation  itself  and  can  be  used  to  emulate  the  communication  delays  between 
the  nodes.  A  relational  database  plus  associated  management  utilities  are 
employed  extensively  by  the  simulation  in  order  to  facilitate  distribution  of  the 
simulation  processes;  communication  between  nodes;  the  sharing  of  common 
information;  and  the  overall  analysis  capability. 

The  overall  development  of  the  DICE  simulation  and  associated  tools  and 
facilities  are  integrated  under  the  DICE  Simulation  Development  and 
Management  Environment  (DSDME).  As  illustrated  in  Figure  2,  this 
environment  has  two  main  streams;  the  Management  stream  and  the  Simulation 
&  Analysis  stream.  The  Management  stream  is  associated  with  the  provision 
and  maintenance  of  general  library  facilities  for  use  by  specific  instances  of  the 
DICE  simulation.  The  Simulation  &  Analysis  stream  is  application  specific  and  is 
concerned  with  the  specification  of  the  C3I  system  to  be  studied  and  the 
development,  simulation  and  analysis  of  particular  scenarios  that  exercise  it. 
This  report  wiU  be  deUvered  by  conveying  the  requirements,  current  status  and 
future  research  and  development  for  the  DICE  simulation  project  in  the  context 
of  the  DSDME  areas.  A  detailed  techiucal  description  of  the  simulation, 
including  a  worked  example  application  and  underlying  mechanics,  is  given  in 
reference  16.  An  overview  of  a  similar  example  is  given  in  Section  5  of  this  report 
along  with  the  perceived  future  research  and  development  activities 
summarised  in  Section  6. 

Software  has  been  implemented  primarily  using  the  ANSI  'C  programming 
language  on  Sun  SPARCstations  with  Graphical  User  Interfaces  (GUI) 
developed  imder  XWindows  and  Windows  4GL. 


3.  DICE  Simulation  Management  Capabilities 

A  goal  of  the  DICE  simulation  project  is  to  establish  and  maintain  libraries  of 
artificial  agents  and  their  building  blocks;  peripheral  units  and  their  interfaces; 
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and  standard  messages.  These  libraries  wiU  then  be  available  for  general  use  by 
specific  instances  of  the  DICE  simulation.  This  goal  is  particularly  demanding  in 
that  the  libraries  must  be  general-purpose  in  nature  and  be  able  to  be  used  in  a 
variety  of  applications.  Realistically,  individual  applications  of  the  DICE 
simulation  can  be  expected  to  result  in  extensions  and  modifications  to  the 
libraries  but  the  aim  is  to  achieve  general-purpose  facilities. 

The  GUI  framework  for  the  DSDME  has  been  developed  and  forms  an 
umbrella  under  which  all  software  and  future  development  is  integrated.  The 
current  version  of  this  environment[16]  embraces  all  of  the  capabilities  reported 
in  this  document;  the  DSDME  will  continue  to  be  modified  as  further 
developments  are  made.  There  are  two  streams  within  the  management  area  of 
the  DSDME;  namely,  agent  management  and  message  management  which  are 
addressed  in  the  following  sections. 

3.1  Agent  management 

The  agent  management  stream  provides  facilities  for  the  general  management  of 
Petri  net  artificial  agents;  peripheral  units  and  their  interfaces;  human  player 
facilities;  measures-of-merit  (MOM);  and  additional  artificial  agents  (non-Petri 
net). 

3.1.1  Petri  net  agent  management 

Extended  Petri  net  (PN)  simulations  form  the  primary  artificial  agent  capability 
within  the  DICE  simulation  to  date.  This  section  wiU  be  used  to  describe  some 
general  requirements  for  artificial  agents  as  well  as  summarising  the  use  of  PN 
(details  of  PN  have  been  reported  separately  in  references  6  to  8). 

The  artificial  agent  management  stream  needs  to  provide: 

•  facilities  for  artificial  agent  development; 

•  facilities  for  artificial  agent  explanation  and  analysis;  and 

•  a  library  of  existing  artificial  agent  building  blocks. 

The  initial  requirement  of  artificial  agents  in  the  DICE  simulation  was  that  they 
be  essentially  rule-based  but  yet  stiU  exhibit  some  important  properties;  namely 
that  a  role-based  methodology  can  be  employed  in  their  design  and 
implementation;  that  they  can  represent  concurrent  and  sequential  processes 
and  resource  sharing;  and  be  clearly  conveyed  to  a  military  domain  expert. 

The  role-based  methodology[8]  involves  a  natural  breakdown  of  the  artificial 
agent  processes  into  smaller  components,  loosely  referred  to  as  roles.  A  role  is 
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not  necessarUy  the  base  element  of  the  agent,  as  in  the  work  of  reference  3,  it  is 
more  a  function,  which  may  in  turn  have  many  roles  within  it.  This  structure 
leads  to  a  hierarchical  design  techiuque,  meaning  that  the  artificial  agent  roles 
can  be  designed  initially  and  then  brought  together  to  form  the  overaU  artificial 
agent,  leading  to  a  bottom  up  design  approach.  Alternatively,  the  designer  can 
initiaUy  sketch  out  the  basic  functions  of  the  artificial  agent  and  then  add  detail 
by  enhancing  its  roles  independently,  leading  to  a  top  down  modelling 
approach.  The  artificial  agent  being  modelled  and  the  information  about  the 
agent  will  determine  which  method  is  most  appropriate  for  the  task  at  hand. 
The  resulting  structure  facilitates  modification  of  agents. 

The  Ubrary  facilities  with  regard  to  artificial  agents,  then,  are  to  make  available 
basic  building  blocks,  namely  roles,  that  can  be  brought  together  to  form  agents 
for  specific  application.  This  is  particularly  important  since  what  constitutes  a 
role  within  an  artificial  agent  of  one  application  may  be  an  artificial  agent  in  itself 
in  another  application. 

C31  networks  involve  many  different  systems  or  entities  working  both 
concurrently  and  sequentially  towards  the  same  main  objective.  This  is  also  true 
for  each  of  the  nodes  in  the  system.  This  is  an  important  feature  of  any  decision 
making  process  and  so  must  be  reflected  in  the  artificial  agent  design  such  that 
the  agent  can  represent  activities  which  occur  in  series  and  in  parallel.  To  some 
extent  this  is  dealt  with  by  taking  the  role-based  approach,  where  roles  can  be 
arranged  according  to  the  way  their  related  functions  occur  in  the  real  system. 


Adequate  credibility  and  reaUsm  in  artificial  agents  is  essential;  judgement  of 
such  qualities  can  generaUy  be  best  made  by  military  domain  experts.  The 
underlying  assumptions  and  characteristics  of  artificial  agents  need  to  be 
conveyable  in  a  form  easUy  imderstood  by  a  military  expert.  Such  an  expert 
should  be  able  to  interrogate  features  of  the  agents,  have  that  agent  explain  its 
actions,  and  to  form  some  judgement  on  the  reaUsm  of  that  artificial  agent 
compared  with  the  real-world  system  that  the  artificial  agent  represents.  Having 
military  endorsement  of  the  assumptions  used  in  such  representations  is  a  vital 
prerequisite  to  any  C31  system  study.  Such  an  explanation  and  analysis 
capability  is  recognised  as  being  important  by  other  researchers  and  developers 
of  computer  generated  forces  (CGF)  in  the  Distributed  Interactive 
Simulation  (DIS)  field[4, 5]. 

Petri  nets  (PN)  where  originally  developed  by  Carl  Petri  as  a  means  of 
modelling  computer  systems.  Since  their  original  conception  they  have  been 
used  to  model  and  analyse  many  different  types  of  systems  including  C31 
systems  and  decision  makers[3].  PN  are  ideal  for  the  modelling  of  event 
systems  which  involve  the  problems  of  resource  sharing,  concurrent  and 
sequential  processes,  and  synchronisation.  The  main  problem  with  PN  is  the 
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growth  in  model  size  as  the  systems  they  represent  become  complex.  To 
overcome  this  problem  PN  have  been  extended  by  the  introduction  of  features 
such  as  coloured  tokens,  firing  modes  and  hierarchies.  These  extensions  allow 
the  user  to  represent  more  complex  systems  in  a  manageable  way;  however, 
they  do  not  increase  the  modelling  power  of  PN. 

The  modular  graphical  representation  of  PN  and  the  hierarchical  extension 
allow  the  role-based  methodology  to  be  easily  applied  during  design[7,  8].  Each 
role  can  be  thought  of  as  a  PN  which  is  then  joined  to  other  PN  via  common 
places  and  transitions  (the  nodes  of  a  PN),  this  allows  each  of  the  roles  to  be 
designed  individually  and  then  brought  together.  Alternatively  a  PN  can  be 
constructed  that  outlines  the  artificial  agent  structure  which  can  then  be  refined 
by  adding  detail.  Hence  a  top-down  or  bottom-up  approach  is  possible.  The 
commercial  software  package  AlphaSIM[18]  is  used  to  design  and  develop  the 
roles  for  PN  agents;  other  packages  are  also  being  investigated. 

PN  were  chosen  over  other  techniques  for  a  number  of  reasons  including  the 
associated  ease  of  modification;  the  underlying  mathematical  foundation;  and  its 
inherent  ability  to  represent  synchronisation,  concurrency  and  resource 
sharing[8]. 

Each  PN  agent  is  implemented  as  an  event-stepping  simulation[6].  Within  the 
PN  simulation  itself,  communication  is  achieved  through  the  passage  of  tokens 
distributed  through  the  firings  of  transitions.  When  an  agent  communicates  with 
the  remainder  of  the  simulation,  however,  it  must  be  done  through  the  standard 
ADFORM  format.  Hence  a  two-way  translation  is  required  between  the 
ADFORM  and  the  PN  languages.  A  user  interface  facility[15]  has  been 
developed  for  the  specification  of  mapping  information  describing  how 
ADFORM  need  to  be  decomposed  into  input  token  attributes  and  how  output 
attributes  are  to  be  used  to  build  ADFORM. 

A  PN  explanation  and  analysis  capability  has  been  established  using  the 
declarative  language  Prolog[7, 8,11].  The  analysis  component  interrogates  a 
given  PN  according  to  user-specified  goals  or  queries  whilst  the  explanation 
capability  abstracts  and  translates  the  query  results  such  that  they  are  presented 
in  a  form  more  easily  understood  to  someone  less  versed  in  PN  notation.  The 
explanation  capability  is  achieved  through  the  use  of  declarative  tags  on  the  PN 
that  describe  the  significance  of  particular  actions  and  state  components. 
Reference  7  is  a  detailed  report  on  this  capability  with  reference  11  reporting  the 
source  code  for  the  software.  A  graphical  user  interface  (GUI)  environment  has 
been  developed  for  this  capability. 
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3.1.2  Peripheral  unit  (PU)  management 
The  PU  management  stream  provides: 

•  Facilities  for  peripheral  unit  interface  (PUI)  development; 

•  Facilities  for  specifying  PU  mformation;  and 

•  A  library  of  existing  PUI  and  associated  mformation. 

Tactical-level  (eg  battlefield)  simulations,  and  maybe  wargames,  would  be  used 
to  represent  activities  that  are  external,  or  at  a  lower  level,  to  the  main  C3I 
simulation  and  help  portray  the  overall  military  mission  concerned.  Such 
representations  allow  the  impact  of  C3I  to  be  gauged  and  hence  associated 
effectiveness  measures  determined.  In  addition,  CSS  may  be  needed  for 
employment  by  human  players.  Interfacing  of  such  peripheral  units  to  the  main 
DICE  simulation  is  achieved  through  Peripheral  Unit  Interfaces  (PUI). 

Library  facilities  with  regard  to  PU,  then,  are  to  provide  access  to  PUI  that  can 
be  employed  as  required  for  specific  appUcation.  It  is  important  to  note  that  the 
intention  is  to  only  have  one  PUI  for  a  given  PU,  ie  a  PUI  is  not  scenario-specific 
but  may  get  extended  to  cover  the  requirements  of  new  scenarios. 

Investigations  have  been  made  into  the  feasibility  of  interfacing  selected 
tactical-level  simulations  and  CSS,  for  scenarios  of  immediate  interest,  with  the 
DICE  simulation.  A  two-way  interface  to  an  in-house  developed  air  picture 
simulation  (ADSIM)[12,19]  has  been  achieved  and  used  to  demonstrate  many  of 
the  concepts  of  the  DICE  project  including  MOE  evaluation  and  the  use  of 
command  support  tools  by  interactive  human  players. 

Significant  breakthroughs  have  been  made  by  the  US  in  the  interoperation  of 
autonomous  distributed  interactive  simulations.  The  evolving  standard  is  that  of 
Distributed  Interactive  Simulation  (DIS) [9,20].  The  general  PUI  development 
discussed  in  previous  paragraphs  only  holds  for  PU  that  are  not  DIS  compliant. 
Efforts  have  been  made  to  make  the  DICE  simulation  compliant  with  DIS 
standards  to  enable  interfacing  with  PU  that  are  possibly  geographically 
distributed.  Such  PU  would  be  themselves  DIS  compHant  and  hence  have  an 
existing  interface  capability.  These  efforts  are  centred  on  developing  what  can  be 
regarded  as  a  DIS  PUI  -  an  interface  into  the  world  of  a  DIS  exercise. 
Communication  in  a  DIS  exercise  is  achieved  through  the  use  of  standard 
messages  referred  to  as  Protocol  Data  Units  (PDU).  The  DICE  simulation’s  DIS 
PUI  is  currently  able  to  receive  and  send  the  main  DIS  PDU  and  this  capability 
has  been  demonstrated.  It  is  important  to  note  that  being  DIS-compliant  helps 
but  does  not  ensure  interoperabiUty.  A  significant  effort  is  still  required  to  form  a 
consistent  simulation  exercise  with  the  credibility  and  fidelity  needed  for 
analysis  or  training. 


9 


DSTO-TR-0485 


(i)  Peripheral  unit  interface  (PUT)  development 

In  general,  PU  such  as  battle  simulations  are  employed  in  a  given  application  to 
help  achieve  the  necessary  depth  and  breadth  to  a  scenario  being  represented. 
PU  are  therefore  expected  to  provide  some  service  to  the  remainder  of  the 
simulation  and  requests  for  such  services  are  in  the  form  of  ADFORM.  Interfaces 
with  PU  are  required  then  to  translate  such  requests  into  appropriate  input 
directives  for  the  PU  concerned.  Similarly,  a  reverse  translation  is  required  from 
the  outcomes  of  the  PU  into  ADFORM.  Matters  that  need  addressing  by  such 
interfacing  include  therefore  the  blending  of  spatial  and  temporal  based  tactical 
models  with  the  message  or  information  flow  based  C3I  simulation.  Although 
some  CSS  may  be  regarded  as  stand-alone  or  off-line,  the  interfacing  problems 
that  apply  to  battlefield  simulations  can  be  considered  to  apply  here  also  except 
that  the  problems  extend  beyond  the  passage  of  messages.  CSS  are  generally 
driven  by  real-world  data  which,  in  the  DICE  environment,  is  simulated.  The  CSS 
will  be  providing  information  to  support  the  commander  that  utilises  it. 

This  environment  provides  facilities  to  develop  and  compile  the  'C  computer 
code  for  a  PUI.  A  skeletal  yet  compilable  framework  is  provided  that,  upon 
execution,  establishes  the  message  input/ output  mechanisms  and  carries  out  all 
the  required  database  transactions. 

(ii)  Peripheral  unit  information 

There  are  two  information  files  associated  with  a  PUI: 

(a)  Stimuli  Format;  and 

(b)  Output  Category. 

The  Stimuli  Format  file  specifies  what  format  the  input  directives  for  the  PU 
need  to  take  and  how  such  directives  should  be  passed  to  the  PU  itself.  Ignoring 
DIS-compliant  PU,  input  directives  might  be  passed  to  a  common  file  or  files 
that  are  monitored  by  the  PU  allowing  sensitivity  to  such  stimuh.  Reference  19 
gives  an  example  of  this  type  of  configuration. 

The  Output  Category  file  includes  the  concept  of  tassels  which  relates  to  the 
PUI  having  a  number  of  arms  emanating  from  it,  the  loose  ends  of  which  need  to 
be  tied  down  when  that  PUI  (and  hence  the  associated  PU  itself)  is  employed  in 
building  a  scenario.  The  tassels  signify  the  different  categories  of  information 
that  a  peripheral  unit  can  supply  to  other  nodes  in  the  simulation.  Tying  of  the 
tassels  specifies  what  entities  in  the  simulation  require  what  information  from 
the  peripheral  unit  and  is  covered  in  Section  4.1.3. 
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available  and  PresmteteTthe*^er'fOT  =>■''! 

tassels  also  holds  for  the  artificial  agents.  d«'elopment.  The  concept  of 


- -  agcxiIS. 

3.1.3  Human  player  facility  management 

A  i_ 


A  number  of  human  player  fadlitip<!  h 

receipt,  creation  and  submission  of  ADFORm  “"  that  permit  the 

can  be  expected  to  arise  as  appiicadon  ofX 

exposure  and  interfacing  with  real  CSS  o  '“"““on  increases  and 

management  stream  will  provide  a  means  of  m™  ®  '’™“  P'’’)'®''  ff^iiiy 

facilities  and  their  use  within  particular  appiiLimf"®  ‘’''“'"’’’“iiy  °f  «iese 

3.1.4  M'^tisure-of-merif  (MOM)  management 

As  discussed  later,  in  order  to  insDect  o,  r  , 

effectiveness  etc,  there  is  a  need  to  design  Ld  ,  T  Performance, 

agent  that  will  compute  such  quantitative  ™P*n'nr^nt  an  associated  artificial 
that  measures  will  be  spec  “p  ^ 

managementstreamwiUprovideagenCaii  "  tthtdies,  this 

3.1.5  Additional  artificial  agent  managemLr 

In  addition  to  PN,  Other  relatively  simnlo  f  u  • 

for  artificial  agents  include  look-up  Ito  easily  adopted 

approaches.  This  management  stream  prr,H  algorithm-based 

administration  of  these  agents.  Capabiiifa  thft  "  “"eMon  and 

the  area  of  artificial  intelligencefl^  mav  be  in  eventuate  from  exploring 

may  warrant  a  separate  faciUtysLuLr  to  “ 

3.2  Message  management 

As  mentioned  earlier,  the  standard 

simulation  is  one  ba'sed“'AXrr“““  -  ‘^e  DiCB 

provides:  The  message  management  stream 

ffl  facilities  for  inspecting  ADFORM  that  originate  from  the  ADF; 

ADFOlSl;tnr  "Peehymg,  modifying  and  inspecting  DICE-specific 

FflcilitiGs  for  spocifyinp^  tlio  I 

mterrogate  and  build  ADFORM  sJfrh  ^  artificial  agents  and  PU  will 

ADFORM  language  and  the  internal  databasTo/rayn™^^^^^ 

MiUes  within  the 

that  can  be  employed  as  required  for  message  structures 

specific  applications.  The  message 
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structures  are  not  scenario-specific  but  it  can  be  expected  that  the  DlCE-specific 
will  cet  extended  to  cover  the  requirements  of  new  scenarios  J 

messages  Will  get  exreiiueu  I  n  iriQDPrt  DICE-specific 

^a,-oocorl  The  ability  to  specify,  modify  and  mspect  F 

Td  "  “  ;•  • 

communication  (including  telephone,  fax  etc)  for  which  ADF  A  g 

not  exist. 


4.  Simulation  &  Analysis 

The  Simulation  &  Analysis  stream  makes  use  of  the  standard 

^^ocird  with  the  management  stream,  to  build,  execute  and  analyse  a  DICE 

simulation  application. 


4.1  Application  Development 


A  f  rairal  anulication  of  the  DICE  simulation  is  configured  about  a  central 
^  /mk  of  nodes  and  links  under  study.  Human  and  artificial  players  need  to 

r  r :  rs:^rani-:;:en-d  rr 

represent  friendly  and  hostile  forces,  sensors  and  other  systems  as  require  . 

The  C31  network  is  exercised  by  a  generated  scenario 
stimuU  for  the  network.  Description  of  suitable  ‘ 

';erfoLnce  (MOP),  measures-o.^flectiveness  (^OE)  ^  m^ 
effectiveness  etc.  This  has  been  chosen  to  putposefuUy  emphasise  g 
purpose  nature  of  the  DICE  simulation.) 

A  variety  of  facilities  have  been  developed  to  support  network  definition  and 
scenario  generation  and  these  ate  covered  in  the  followmg  sections. 

4.1.1  Network  definition 

r>,  (  tiirp  nf  the  application  deyelopment  suite  of  tools  is  a  general  purpose 

of  nodes  and  links.  This  tool  is  used  m  thts  strei^  tailored 

is  central  to  the  application.  Both  nodes  and  h^  cm  be  J  ^ 

rraUniQ  and  havo  associated  general  information  that  mciuae  h 

identifiers  and  descriptions.  Multiple  links  can  be 

represent,  for  example,  different  communication  channels  or  media. 
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The  characteristics  of  a  commumcation  channel  is  currently  limited  to  a 
deterministic  or  stochastic  transmission  time.  For  flexibility,  in  a  two-way 
communications  link  the  transmission  time  (or  the  parameters  that  affect  it)  can 
be  different  for  each  direction.  A  more  sophisticated  communications  model  may 
be  acquired  or  developed  in  the  future  that  takes  explicit  account  of  link 
bandwidth  and  the  actual  traffic  on  a  link  at  any  instant  during  the  simulation. 

The  link  characteristics  are  specified  by  the  user  within  the  ScenGenDraw 
environment  and  stored  with  each  visual  link.  This  information  is  directly  used 
by  the  simulation  as  discussed  later.  ScenGenDraw  also  allows  free-text  storage 
of  general  notes  against  each  node  and  link  which  is  useful  for  general  system 
specification  and  application  development. 

In  terms  of  the  eventual  simulation,  the  overall  output  from  this  environment 
is  the  network  nodes  and  links,  their  description  and  their  connectivity. 
Connectivity  is  described  using  link  names,  source  and  target  node  names  and 
the  transmission  time  information  for  each  link  direction. 

The  Simulation  Controller  node  is  automatically  generated  which  corresponds 
to  the  run-time  monitoring  and  control  facilities  associated  with  the  simulation 
controller.  Each  node  has  the  ability  to  communicate  with  the  Controller  node 
and  the  necessary  links  are  automatically  generated. 

The  C3I  network  that  results  from  the  ScenGenDraw  fadHty  has  the  potential 
to  be  used  for  run-time  display. 

4.1.2  Overall  scenario  definition 

This  stream  concerns  the  specification  of  how  the  central  C31  network  will  be 
exercised.  The  current  capabilities  are  adequate  but  can  be  considerably 
enhanced  leading  to  a  more  sophisticated  graphics-based  environment  and 
improvements  in  overall  robustness.  This  would  include  map  displays  and  the 
ability  to  specify  from  those  displays  information  pertaining  to  own  and  enemy 
forces,  their  initial  status,  rules  of  engagement  (ROE)  and  intentions  or  plans. 

However  sophisticated  the  desired  scenario  generation  capability,  the  resultant 
output  has  to  be  translated  into  stimuli  that  will  prepare  every  node  agent, 
peripheral  unit  and  human  player  facility  for  simulation  execution  and  stimulate 
such  nodes  during  run  time.  In  the  DICE  simulation  architecture,  the 
conveyance  of  such  stimuli  is  achieved  through  ADFORM.  With  the  absence  of 
sophisticated  user  facilities,  the  scenario  generation  capability  currently  consists 
of  the  ability  to  directly  specify  the  stimuli  as  ADFORM  messages. 

This  facility  addresses  specification  of  the  initial  state  of  the  scenario  and  the 
scheduling  of  pre-determined  stimuli.  Such  stimuK  are  referred  to  as  independent 
since  they  are  pre-scheduled  to  occur  at  certain  times  in  the  simulation,  and 
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hence  are  independent  of  activities  that  occur  whilst  the  simulation  is  running. 
Independent  stimuli  can  be  received,  and  considered  sent,  by  any  node  in  the 
simulation;  early  stimuli  form  the  initial  drive  to  the  simulation.  Initial 
independent  stimuli  might  specify  the  initial  position,  state  and  perceived  intent 
of  enemy  entities;  the  initial  ROE;  and  the  initial  military  objectives  of  the  blue 
force.  Independent  stimuli  scheduled  to  occur  during  run-time  might  represent 
aspects  such  as  pre-determined  additional  enemy  activity. 

Specification  of  the  ADFORM-based  independent  stimuli  involves  selecting  the 
format  and  building  message  content;  selecting  intended  recipients;  and 
scheduling  message  submission[15].  When  specifying  the  recipients  of 
independent  stimuli,  the  option  is  available  for  either  direct  transmission  to  the 
recipient  or  transmission  via  the  communications  module  of  the  simulation 
kernel.  In  order  to  minimise  the  processing  that  occurs  at  the  commencement  of 
execution,  some  independent  stimuli  can  be  flagged  as  initialisation  messages 
which  are  subsequently  handled  before  simulation  time  t  -  0. 

4.1.3  Peripheral  unit  allocation 

This  stream  allows  peripheral  units  (PU)  to  be  selected  from  the  standard  hbrary 
and  configured  via  their  PUI  into  the  scenario  concerned.  PU  will  be  selected 
based  on  what  service  is  required  of  them  in  the  scenario. 

As  discussed  earlier,  each  PUI  (and  hence  the  associated  PU)  can  be  considered 
having  a  number  of  tassels  emanating  from  it  which  correspond  to  particular 
types  of  categories  of  information  that  that  PU  can  provide  to  other  nodes  in  the 
simulation.  The  information  takes  the  form  of  ADFORM.  These  tassels  need  to 
be  tied  down  to  particular  recipients  with  the  default  being  to  link  tassels  to 
nobody.  Multiple  recipients  of  information  are  allowed  and  PUI  can  broadcast 
all  information  to  all  nodes  if  required.  This  broadcast  characteristic  typifies 
current  DIS  exercises [9,20].  The  specific  link  on  which  the  messages  are  to  be 
submitted  must  also  be  stated.  Also,  the  option  of  transmitting  or  not 
transmitting  the  messages  via  the  kernel  communications  module  is  again 
available. 

4.1.4  Measure-of-merit  (MOM)  allocation 

The  MOM  definition  facility  can  be  regarded  as  allowing  use  of  an  artificial 
agent  that  calculates  the  MOM  that  are  considered  to  apply  in  a  given  scenario. 
A  number  of  MOM  might  be  appropriate  and  this  facility  also  includes  the 
ability  to  specify  mission  requirements  for  each  MOM.  Mission  requirements 
currently  take  the  form  of  lower  and  upper  bounds  on  each  MOM.  The  resultant 
MOM  values  can  be  compared  during  nm-time  and  in  post-simulation  analysis 
against  mission  requirements  to  determine  the  extent  to  which  the  requirements 
have  been  met.  In  the  case  of  a  MOM  which  is  regarded  as  a  MOP,  observing  the 
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MOP  of  a  system  and  comparing  observations  against  requirements  is  one 
means  of  judging  the  overall  effectiveness  of  that  system. 

Although  the  general  philosophy  for  effectiveness  analysis  in  the  DICE 
simulation  is  based  on  inspecting  the  impact  of  C31  on  an  overall  military 
objective,  it  is  important  to  note  that  any  quantitative  MOM  can  be  calculated 
and  used  in  a  study.  An  artificial  agent  (a  MOM  agent)  would  be  designed  to 
compute  the  required  measure  and  be  configured  to  receive  input  information 
from  other  nodes  as  needed  [16]. 

The  concept  of  tassels  appUes  to  MOM  agents  also  in  that  the  service  they 
provide  are  the  MOM  calculations  which  need  to  be  assigned  to  appropriate 
recipients.  The  recipient  of  MOM  calculations  is  generally  the  Controller  node 
which  might  consequently  display  the  calculations  to  the  analyst. 

4.1.5  Petri  net  allocation 

This  stream  allows  Petri  net  artificial  agents  to  be  selected  from  the  standard 
library  and  configured  as  players  in  the  DICE  simulation.  Players  represent  the 
nodes  of  the  central  C31  network  and  a  number  of  artificial  players  may  be 
required  with  their  detail  being  dependent  on  what  service  is  required  of  them  in 
the  scenario.  Such  agents  are  formed  through  adoption  of  the  role-based 
methodology  discussed  in  Section  3.1.1.  The  concept  of  tassels  applies  to 
artificial  players  also. 

For  completeness,  it  is  mandatory  that  artificial  players  are  allocated  to  each 
node  in  the  central  C31  network  regardless  of  intended  human  player  allocation. 
This  is  important  and  aUows  multiple  executions  of  the  simulation  to  be 
achieved  without  the  presence  of  the  original  human  players. 

4.1.6  Human  player  allocation 

The  main  function  associated  with  the  human  players  in  the  simulation,  is  the 
ability  to  receive,  create  and  submit  messages  such  that  communication  with  the 
remainder  of  the  simulation  is  achieved.  GUI  environments  have  been 
established  that  provide  such  a  capability[15].  An  overall  goal  is  to  utilise 
original  or  tailored  versions  of  operational  software  that  provide  this  capability 
to  real-world  military  personnel.  The  ADFORM  Interface  Machinery  (AIM) 
software,  developed  for  the  ADF,  is  an  example  of  operational  software  that  will 
be  configured  as  an  optional  feature  within  the  DICE  simulation  architecture;  its 
longer-term  adoption  will  be  dependent  on  the  associated  throughput  and  ease 
of  integration  and  use.  Interfacing  to  real-world  CSS  has  not  been  attempted  to 
date,  although  the  basic  concepts  have  been  demonstrated  using  the  ADSIM 
model. 

This  stream  allows  specification  of  what  software  will  be  used  to  form  the 
stations  for  human  players  in  the  DICE  simulation.  Although  possibly  standard 
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across  scenarios,  such  allocation  includes  the  facilities  that  will  be  used  by  the 
simulation  controller. 

When  applying  the  DICE  simulation,  clear  intentions  are  essential  concerning 
what  key  areas  or  capabilities  of  the  represented  C3I  system  were  to  be 
addressed.  The  presence  of  human  players  in  a  simulation  exercise  increases  the 
likelihood  of  the  simulation  taking  a  course  that  is  not  on  path  to  meeting  the 
overall  objectives  of  the  exercise.  The  controller  needs  to  be  able  to  recognise 
such  situations  and  influence  the  simulation  during  run-time  in  order  to  nudge  it 
back  on  course.  The  controller  needs,  therefore,  to  be  able  to  communicate  with 
all  players  (real  or  artificial)  and  to  inject  stimuli  during  run-time  into  the 
simulation.  The  controller  can  secretly  pretend  to  be  any  one  player  and  send 
messages  to  others  if  he  wishes  to  influence  the  simulation  execution  in  that 
way.  The  controller  can  pause,  advance  and  resume  the  simulation  as  needed. 
The  controller  facilities  are  extended  versions  of  the  human  player  facilities  and 
allow  the  controller  to  cover  any  minor  incompleteness  in  the  scenario  that  has 
occurred  through  error  in  scenario  generation[15]. 

4.1.7  Additional  artificial  agent  allocation 

Additional  artificial  agents  are  required  to  further  populate  the  simulated 
scenario  and  represent  entities  or  activities  that  are  considered  external  to  the 
central  C3I  network  and  have  not  been  covered  by  peripheral  units.  Their 
allocation  is  identical  to  that  of  artificial  players  discussed  in  Section  4.1.5. 
Examples  of  such  agents  are  enemy  force  behaviour  and  look-up  tables  of  sensor 
capabilities. 

4.1.8  Pre-implementation  analysis 

Some  analysis  capability  is  desirable  at  the  scenario  generation  stage  to  check, 
for  example,  the  completeness  and  fidelity  of  the  specified  scenario  and  make 
some  predictions  of  the  sequence  of  events  that  might  occur.  Currently  simple 
connectivity  checks  are  made  on  the  C31  network  but  additional  desired 
capabilities,  not  yet  implemented,  include: 

•  Preliminary  execution  of  artificial  agents; 

•  Simulation  performance  predictions  including  inspection  of  what  data 
staleness  or  latency  might  occur  and  whether  it  can  be  adequately 
compensated  for; 

•  Consideration  of  the  distributed  nature  of  the  simulation  and  whether  the 
multiple  processes  have  been  sufficiently  distributed  between  available 
processors. 
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Currently,  the  only  substantial  pre-implementation  analysis  capability  is 
provided  by  access  to  the  PN  explanation  and  analysis  capability. 

4.2  Simulation  implementation  and  execution 

4.2.1  Simulation  implementation 

The  application  development  stage  results  in  a  coUection  of  interrelated  flat  files 
that  contain  a  full  description  of  the  C31  network  and  the  external  environment 
and  scenario  that  drive  it.  In  preparation  for  actual  execution,  the  data  needs  to 
be  implemented  in  a  form  understandable  to  the  run-time  mechanisms  of  the 
simulation.  This  involves  converting  the  flat  file  representations  into  appropriate 
tables  within  an  lngres[10]  relational  database.  A  GUI  environment  has  been 
developed  that  provides  this  capability  for  a  user-selected  application. 

The  database  design  of  the  DICE  simulation  is  detailed  in  reference  16;  the 
specific  application  information  is  converted  into  rows  of  data  in  the  following 
tables.  The  environment  allows  viewing  of  each  of  the  resultant  tables. 

Node  Table:  this  table  stores  a  description  of  the  node;  the  processor  that  the 
associated  process  wiU  execute  on;  and  the  type  of  node  (eg  Petri 
net,  MOM  etc.) 

Link  Table:  this  table  stores  the  type  of  link  (eg  radio,  fax  etc.);  the  source  and 
target  nodes  that  that  link  connects;  transmission  time  information; 
and  the  current  link  availability.  Links  can  be  available,  not 
available  and  notifiable  (in  which  case  the  link  is  unavailable  but 
any  node  that  wishes  to  use  that  link  gets  informed  of  its  state). 

Independent  Stimuli  Table:  this  table  stores  independent  stimuli,  their  scheduled 
time  and  indications  of  which  are  for  initialisation  purposes. 

Scenario  Infotmation  Table:  this  table  stores  the  simulation  execution  rate, 
multiple  execution  requirements  and  latency  recording  option 
setting. 

Scenario  information  not  placed  into  tables  at  this  stage  concerns  tassels  and 
their  allocated  recipients.  This  information  is  addressed  in  the  initialisation 
phase  of  simulation  execution. 

Also  included  in  this  facility  is  the  abihty  to  specify  requirements  for  multiple 
executions  of  the  simulation.  This  takes  two  forms.  The  first  allows  specification 
of  parameter  variations  (in  the  form  of  mitial  and  final  value  and  increment)  that 
need  to  be  observed  from  run  to  run.  The  second  is  the  specification  of  the 
number  of  runs  required  for  Monte  Carlo  style  execution  in  order  to  observe  the 
statistical  nature  of  an  application.  For  each  set  of  parameter  values,  the  number 


17 


DSTO-TR-0485 


of  Monte  Carlo  executions  are  carried  out.  Parameters  might  describe  the 
behaviour  of  nodes,  links  or  peripheral  units  provided  these  entities  are  'data- 
driven  to  allow  their  behaviour  to  be  altered  between  executions. 

The  central  DICE  simulation  is  typified  by  multiple  processes  corresponding  to 
individual  artificial  agents,  PUl  etc.  Each  process  can  execute  on  any  processor 
that  has  access  to  the  core  Ingres  RDBMS.  Part  of  the  simulation  implementation 
facihty  involves  specification  of  how  each  process  should  be  distributed [16]. 

4.2.2  Simulation  execution 

Simulation  execution  is  in  two  distinct  phases;  an  initialisation  phase  and  a  run¬ 
time  phase[16]. 

(i)  Irutialisation  phase 

The  initialisation  phase  prepares  all  scenario  node  processes  for  simulation.  This 
phase  involves: 

•  Establishing  node  processes  on  specified  processors; 

•  Establishment  of  mailboxes  and,  where  appropriate,  tassel  tables  for  all 
nodes; 

The  mailboxes  are  database  tables  that  store  and  allow  retrieval  of 
incoming  message  identities.  The  tassel  tables  describe  the  tassel 
allocation  for  a  given  node. 

•  Registration  for  database  events; 

Database  events  are  triggered  when  certain  actions  (eg  an  entry)  are 
made  on  database  tables.  Such  events  are  used  to  indicate,  for  example, 
message  arrival  to  recipients[16]. 

•  Conveyance  of  initialisation  information  (appropriately  flagged 

independent  stimuli)  to  each  process  and  the  accommodation  of  that 
information  by  the  recipient  process; 

•  Conveyance  of  readiness  by  node  processes  to  simulation  controller. 

Having  an  initiahsation  phase  separate  from  the  run-time  phase  is  particularly 
important  since  it  prevents  initialisation  activities  from  having  an  affect  on  nm- 
time  analysis.  For  example,  accommodation  of  initialisation  information  by  a 
PUI  may  take  some  time  since  such  information  may  be  substantial  and 
essentially  dictates  to  the  associated  PU  what  its  initial  state  should  be. 
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In  contrast  to  the  run-time  phase,  during  initialisation  the  processes  are  free  to 
execute  as  fast  as  possible  since  there  is  no  inter-process  communication 
required.  When  all  processes  have  conveyed  their  readiness,  the  simulation  is 
essentially  put  in  a  pause  mode  prior  to  the  simulation  controller  placing  the 
simulation  into  the  run-time  phase. 

(ii)  Rrm-time  phase 

The  execution  of  the  simulation  during  run-time  is  characterised  by  the 
submission  of  messages  by  nodes  for  transmission  and  the  receipt  of  messages 
by  nodes.  The  communication  architecture  associated  with  the  simulation  is 
illustrated  in  Figure  3  where  each  node  is  treated  in  an  identical  marmer.  Each 
node  has  an  associated  mailbox  through  which  it  receives  incoming  messages. 
Outgoing  messages  from  a  node  can  either  be  sent  directly  to  recipients  (not 
shown  in  Figure  3)  or,  if  a  communication  channel  needs  to  be  utilised,  can  be 
sent  via  the  communications  module  of  the  simulation  kernel.  The 
communications  module  is  designed  around  two  main  events:  message 
submission  and  message  reception.  Message  submissions  get  translated  into 
receptions  scheduled  to  occur  after  an  appropriate  communication  delay  or 
transmission  time. 

The  kernel  also  controls  time  synchronisation  and  execution  rate  of  the 
distributed  processes  and  can  be  configured  such  that  the  simulation  can  run  in 
real  or  non-real  time.  The  simulation  is  capable  of  being  paused,  advanced  and 
resumed  as  required  by  the  simulation  controller.  The  simulation  controller  can 
also  influence  the  simulation  by  injecting  messages  as  external  or  other  stimuh; 
altering  the  availability  and  nature  of  communication  links. 

The  simulation  is  typically  initiated  by  pre-scheduled  stimuli  and  ends  at  a  pre¬ 
set  instant  or  following  a  decision  by  the  simulation  controller.  The  information 
flow  between  nodes  is  captured  by  logging  every  message  in  the  Ingres 
database.  This  involves  storing  the  message  content  along  with  the  time  it  was 
sent  and  received,  the  sender  and  recipient.  Such  logging  will  automatically 
cover  any  messages  associated  with  MOM  computations.  The  internal  behaviour 
of  Petri  net  artificial  agents  can  also  be  recorded  for  later  inspection.  Peripheral 
units  would  generally  be  left  to  their  own  devices  regarding  the  logging  of 
internal  behaviour;  for  example,  the  ADSIM  PU  makes  its  own  record  that  can 
be  used  for  simulation  replay. 

Against  each  message  transaction  can  be  recorded  data  latency  figures  which 
indicate  to  what  extent  the  processing  of  messages  has  been  delayed  owing  to 
the  performance  of  the  simulation  and  the  network  it  utilises.  For  example,  a 
message  may  be  scheduled  for  reception  by  a  node  at  a  simulation  time  of  230  s 
but  may  not  actually  be  picked  up  by  that  node  until  232  s.  Such  latency  needs  to 
be  taken  mto  account  in  any  quantitative  analysis  that  is  carried  out  following 
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the  simulation.  Consideration  of  the  latency  figures  also  provides  a  means  of 
determining  the  optimal  distributive  arrangement  for  the  simulation's  multiple 
processes.  When  monitoring  such  latency  it  is  important  to  be  aware  of  the  effect 
on  performance  of  the  'probe'  itself;  this  is  a  difficult  problem.  For  this  reason, 
the  latency  trapping  is  configured  as  an  optional  capability. 

The  controller  facilities  also  include  the  optional  ability  to  view  the  current  and 
historical  latency  figures  and  their  variation  over  time.  Another  option  is  the 
ability  to  monitor  the  message  rates  associated  with  each  node  and  link. 

At  the  end  of  an  execution  the  resultant  database  tables  are  translated  into  flat 
file  format  for  subsequent  analysis.  This  is  also  true  for  each  individual 
execution  in  a  multiple  execution  batch.  Against  each  execution  is  stored  details 
of  the  parameter  values  used  in  that  run;  in  the  case  of  single  executions,  a 
baseline  value  is  assumed. 

4.4  Post-simulation  analysis 

Post-simulation  analysis  capabilities  need  to  include  inspection  of  C3I  system 
characteristics  such  as  bottlenecks;  command  and  information  flow;  and 
effectiveness  measures.  A  history  and  review  function  is  also  needed  that 
provides  the  ability  to  select  and  replay  aspects  of  the  simulation,  including 
analysis  of  the  impact  of  key  commands  or  decisions  made  by  artificial  or 
human  players.  Configuration  of  the  simulation  kernel  about  an  Ingres  database 
wiU  facilitate  establishment  of  this  analysis  capability  but  has  not  been 
developed  to  date. 

The  post-simulation  analysis  capabilities  developed  to  date  include  the  ability 
to  inspect  all  information  associated  with  an  individual  execution,  including 
individual  executions  belonging  to  a  batch.  This  is  achieved  by  re-mapping  the 
flat  file  output  into  database  tables  to  facilitate  querying.  Inspection  of  the 
message  transactions  that  occurred  in  an  execution  is  a  superficial  means  of 
determining  points  of  congestion;  more  rigorous  techniques  are  planned  as 
future  development.  The  activity  associated  with  a  particular  node  or  Link  can  be 
determined  through  appropriate  queries,  and  the  internal  activity  of  any  node 
can  be  inspected  through  interrogation  of  the  associated  log  of  events.  If  such 
information  were  trapped  during  the  execution,  a  review  of  the  simulation 
performance  is  possible  through  analysis  of  the  data  latency  figures. 

In  the  case  of  multiple  executions,  summary  information  from  each  individual 
execution  in  the  batch  is  interrogated  and  a  means  of  analysing  this  information 
in  terms  of  pre-specified  MOM  is  provided  as  discussed  later  in  this  section. 
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The  essence  of  the  C3I  system  effectiveness  analysis  for  which  the  DICE 
simulation  is  designed  is  based  on  the  philosophy  of  inspecting  the  impact  of 
C3I  on  some  overall  military  mission.  Appropriate  MOM  would  need  to  be 
determined  to  reflect  this  and  might  be  scenario-specific  rather  than  generic.  The 
DICE  simulation  environment  allows  any  quantitative  measure  to  be  calculated 
and  in  this  regard  is  therefore  general-purpose.  As  discussed  earlier,  against 
each  measure  can  be  specified  mission  requirements  which  are  currently  limited 
to  lower  and  upper  botmds  for  each  MOM.  A  number  of  MOM  may  be 
employed  in  any  application  in  which  case  the  mission  requirements  describe  a 
region  in  space  within  which  the  MOM  values  must  lie  in  order  for  the 
requirements  to  be  met.  This  is  illustrated  later  in  this  section. 

The  post-simulation  analysis  capability  allows  the  MOM  values  (observations 
of  the  system)  eventuating  from  simulation  executions  to  be  compared  against 
requirements. 

Some  measures  may  vary  with  simulation  time  leading  to  some  final  value 
which  is  deemed  to  be  indicative  of  the  system  under  study.  Owing  to  the 
availability  of  all  message  information,  the  post-simulation  analysis  facilities  for 
individual  executions  permit  interrogation  of  the  variation  in  MOM  observations 
over  time  and  inspection  of  how  this  variation  compares  with  the  bounds 
described  by  the  mission  requirements.  All  or  some  of  the  measures  can  be  used 
for  the  comparison. 

Multiple  executions  of  the  simulation  produce  a  collection  of  observations  of 
system  MOM  under  parameter  variation  and  statistical  sampling.  Confidence 
levels  for  the  samples  need  to  be  determined  and  further  executions  made  as 
required. 

Let  the  system  MOM  be  denoted  by  MOM;  where  z  =  1  to  n,  where  n  is  the 
number  of  MOM  used  to  describe  the  system.  Let  the  mission  requirements  be 

denoted  by  MR  =  fy  (MOMj,  MOM2, . ,  MOM„)  where  /  =  1  to  m,  where  m  is 

the  number  of  functions  needed  to  describe  the  mission  requirements.  The 
collection  of  functions  that  make  up  the  mission  requirements  can  be  regarded 
as  describing  a  region  in  n  dimensional  space. 

Each  execution  of  the  simulation  will  generate  individual  values  or 
observations  for  each  MOM  and  hence  describe  a  point  in  this  space.  Multiple 
executions  will  result  in  a  distribution  of  points;  some  lying  within  the  region, 
others  outside.  In  the  work  of  references  13  and  14,  the  percentage  that  lie  within 
mission  MOP  requirements  region  is  taken  to  be  the  overall  system  effectiveness. 

As  a  simple  example,  consider  the  1 -dimensional  case  where  system 
performance  is  characterised  by: 
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MOPj  =  Reaction  Time 

and  the  mission  requirements /j(MOP3)  are  expressed  as: 

MOP3  <  5  minutes. 

The  outcome  of  multiple  executions  of  the  simulation  might  be  a  distribution 
from  MOP3  =  2  to  8  minutes  (ie  a  range  of  6  minutes),  shown  in  the  figure  below. 


Assuming  a  imiform  distribution  for  MOP3 ,  this  would  imply  that  the  system 
is  50%  effective.  However,  if  system  performance  was  characterised  by  some 
skewed  distribution  then  the  overall  effectiveness  would  be  less  than  or  greater 
than  50%  depending  on  where  the  bias  lay.  Multiple  executions  of  the  simulation 
would  identify  such  a  distribution  and  reflect  this  in  the  associated  results. 

The  above  example  can  be  extended  into  multiple  dimensions  and  also  where 
the  mission  requirements  were  functions  of  more  than  one  MOM 
(eg  MOM32  +  MOM22  >  0). 

In  the  DICE  post-simulation  analysis  environment,  a  collection  of  final  values 
corresponding  to  each  MOM  is  used  to  analyse  multiple  executions  in  batches. 
The  percentage  of  'hits'  within  the  mission  requirements  region  is  compared 
with  the  total  population.  As  in  the  case  of  individual  executions,  the  selection  of 
which  measures  to  use  in  the  analysis  is  possible. 

A  record  of  the  complete  analysis  session,  consisting  of  queries  and  their 
outcomes,  is  recorded  for  future  reference. 


5.  Example  Application 

In  order  to  consolidate  the  previous  sections  of  this  document,  an  example 
application  will  be  conveyed.  A  similar  example  is  employed  within  reference  16 
which  gives  a  detailed  account  of  the  mechanics  of  the  simulation.  This  section 
will  be  superficial  in  comparison  but  is  intended  to  convey  a  t)^ical  use  of  the 
various  components  that  make  up  a  DICE  simulation  application.  The  example 
is  for  illustrative  purposes  only  and  is  not  intended  to  be  indicative  of  any  real 
system. 
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5.1  Overall  system 

The  C3I  system  to  be  studied  in  any  application  would  typically  be  part  of  some 
broader  system.  Consider  the  example  of  an  air  defence  system  consisting  of 
sensing,  collation  of  information  and  response  as  shown  in  Figure  4.  The  sensors 
are  Over-The-Horizon-Radar  (OTHR),  Ground-Based  Radar  (GBR)  and  Airborne 
Early  Warning  and  Control  (AEW&C).  Information  from  the  sensors  is  passed  to 
a  Regional  Correlation  Centre  (RCC)  which  collates  this  information,  fuses  it  and 
forwards  a  Recognised  Air  Picture  (RAP)  to  various  nodes  in  the  C3I  system. 

The  recipients  of  the  RAP  are  the  Sector  Air  Defence  Operations 
Centre  (SADOC),  the  Tactical  Air  Operations  Centre  (TAOC)  and  the  Control 
Element  (CE).  The  coimnander  in  the  SADOC  monitors  the  RAP,  is  responsible 
for  all  air  defence  operations  within  the  sector  and  contributes  to  the  situation 
awareness  of  higher  command  (the  National  Air  Defence  Operations 
Centre  (NADOC)).  The  TAOC  also  monitors  the  RAP  and  is  responsible  for 
setting  and  maintaining  the  posture  of  its  air  defence  assets  which  in  this  case 
are  (blue)  intercept  aircraft.  This  is  maintained  through  directives  to  the  fighter 
aircraft  squadron  (SQN)  and  assigning  control  of  intercept  aircraft  to  the  CE. 

The  CE  is  responsible  for  directing  assigned  intercept  aircraft  to  hostile  (red) 
aircraft  tracks.  This  is  achieved  by  monitoring  aspects  of  the  RAP  and  directing 
the  fighters  accordingly. 

5.2  C3I  system  and  scenario 

Consider  the  C3I  system  for  study  to  consist  of  the  RCC,  NADOC,  SADOC, 
TAOC,  CE  and  SQN  as  shown  in  Figure  5.  That  is,  excluding  the  capabilities  of 
the  air  defence  assets  such  as  the  sensors  and  the  intercept  aircraft.  The  key 
features  that  might  be  inspected  in  this  system  are  timeliness  and  quality  of 
information  and  decision  making. 

In  order  to  conduct  such  an  inspection  using  the  DICE  simulation,  a  scenario 
that  exercises  the  C3I  system  needs  to  be  defined.  That  is,  a  scenario  that  both 
stimulates  the  system  and  is  also  influenced  by  that  system.  In  this  case,  the 
scenario  can  be  considered  to  be  where  red  aircraft  are  conducting 
reconnaissance  missions.  The  surveillance  assets  of  the  blue  force  have  some 
capability  to  detect  the  red  activity  and  convey  this  to  the  C3I  system.  Within  the 
C3I  system  decisions  need  to  be  made  regarding  the  nature  of  the  activity  which 
will  eventually  lead  to  the  scrambling  and  directing  of  blue  intercept  aircraft. 

The  following  sections  will  outline  how  such  a  system  and  scenario  might  be 
represented  within  the  DICE  simulation  in  order  to  permit  an  assessment  of  the 
surveillance,  dissemination,  assessment  and  response  process  discussed  above. 
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5.3  Representing  the  C3I  system 

The  C3I  system  to  be  studied  is  typically  represented  within  the  simulation 
through  the  use  of  artificial  agents,  human  players  and  communication  link 
delays.  There  are  numerous  optional  configurations  that  can  be  established 
ranging  from  full  automation  using  one  or  many  artificial  agents  to  the  inclusion 
of  one  or  more  human  players. 

5.3.1  Human  player  allocation 

It  may  be  more  appropriate  to  utilise  a  human  player  to  represent  a  node  of  the 
C3I  system  than  an  artificial  agent.  This  may  be  owing  to  a  lack  of  data  that 
permits  an  adequately  realistic  artificial  representation  or  it  may  be  desirable 
from  a  training  or  knowledge  elicitation  pomt-of-view. 

Consider  the  case  where  the  TAOC  node  were  represented  by  a  human  player, 
as  shown  in  Figure  6.  The  ADFORM  facilities  reported  in  reference  15  would 
currently  be  used  to  permit  the  receipt,  creation  and  submission  of  messages  by 
the  player.  In  addition,  the  player  might  be  presented  with  some  CSS  to  assist 
his  decision-making  process.  The  concept  of  a  CSS  is  exemplified  in  later  sections 
with  the  use  of  a  second  copy  of  the  ADSIM  peripheral  unit.  In  the  longer  term, 
alternative  messaging  and  CSS  might  be  employed. 

The  TAOC  player  would  receive  formatted  textual  messages  from  the  RCC  that 
convey  the  RAP  as  well  as  directives  and  approvals  from  the  SADOC.  The 
TAOC  player  would  monitor  the  air  picture  and  make  decisions  regarding  the 
formation  and  maintenance  of  aircraft  alert  states  and  Combat  Air  Patrols  (CAP). 
Definition  and  maintenance  of  such  posture  of  the  air  defence  assets  would  be 
achieved  through  communication  via  formatted  textual  messages  to  the  SQN 
node.  Decisions  to  scramble  intercept  aircraft  to  meet  hostile  tracks  might 
require  approval  from  the  SADOC  commander  which  would  be  addressed 
through  identical  cormnunication  means. 

5.3.2  Artificial  agent  allocation 

The  remainder  of  the  C31  network  nodes  would  be  represented  through  the  use 
of  artificial  agents  (see  Figure  7)  which,  to  date,  would  primarily  consist  of  PN 
simulations.  Rules  that  define  the  behaviour  of  each  node  would  be  represented 
within  the  PN.  In  the  case  of  the  CE,  for  example,  rules  would  be  implemented 
that  reflect  how  that  node  responds  to  tasking  from  the  TAOC;  how  it 
commtmicates  with  intercept  aircraft;  and  what  information  is  conveyed. 
Associated  with  all  such  rules  is  time  information;  namely,  how  long  does  it  take 
to  conduct  a  particular  action.  Such  tunings  can  be  of  fixed  or  variable  duration. 

Each  PN  node  would  have  an  associated  tassel  file  that  indicates  what 
information  will  be  provided  by  a  node  to  others.  For  example,  the  RCC  is 


24 


DSTO-TR-0485 


capable  of  providing  a  RAP  message  and,  in  this  case,  this  tassel  will  be  tied  to 
the  SADOC,  TAOC  and  CE  who  are  the  intended  recipients  of  this  information; 
other  nodes  will  not  receive  that  type  of  message.  Each  net  also  has  associated 
input  mapping  information  which  indicates  what  ADFORM  that  agent  is  able  to 
accept  and  how  it  is  translated  into  the  internal  database  of  that  agent.  Similarly, 
there  is  output  mapping  information  also. 

5.3.3  Communications 

Communications  delays  can  be  represented  by  a  number  of  means.  For  example, 
consider  the  time  delay  associated  with  the  transfer  of  the  RAP  between  the  RCC 
and  the  SADOC.  If  these  nodes  were  implemented  as  one  node  in  the  DICE 
simulation  then  the  time  delay,  or  the  communication  protocol  that  results  in 
that  delay,  would  be  incorporated  within  that  node  also.  If  the  RCC  and  the 
SADOC  were  implemented  as  separate  artificial  agents  then  the  communications 
delay  between  the  two  can  be  represented  by  one  of  two  means.  Entries  could  be 
put  in  the  Ingres  database  that  specify  either  a  fixed  or  statistically  distributed 
time  delay  between  the  two  nodes.  Alternatively,  PN  could  be  used  to  provide 
detailed  communications  models  for  links.  In  the  latter  configuration,  the 
communications  delay  between  the  RCC  and  the  link  agent  would  be  zero,  the 
actual  delay  would  be  computed  within  the  link  agent,  and  a  zero  delay  would 
apply  between  that  agent  and  the  SADOC. 

5.4  Representing  the  air  defence  assets 

In  the  example  application  of  Figures  4  to  9  there  is  a  need  to  represent  sensor 
capabilities  and  aircraft  movement.  Given  the  current  repertoire  of  tactical 
models,  this  requirement  could  be  addressed  through  the  use  of  one  copy  of  the 
ADSIM  model  (ADSIMl,  as  shown  in  Figure  8).  In  this  role,  ADSIMl  represents 
ground-truth  information  in  that  it  generates  the  true  air  picture.  The  graphical 
display  capabilities  of  ADSIMl  would  be  useful  to  the  simulation  controller  in 
monitoring  the  course  of  the  simulation. 

The  two-way  interface  ADSIM  PUI  would  be  employed  with  ADSIMl. 
Detection  information  from  the  surveillance  assets  would  be  output  from 
ADSIMl,  converted  into  appropriate  messages  and  sent  to  the  RCC  node. 
Aircraft  that  become  airborne  due  to  the  actions  of  the  TAOC  would  be 
conveyed  to  ADSIMl  from  the  SQN  node  by  a  textual  message  which  gets 
converted  into  appropriate  input  directives  for  ADSIMl,  resulting  in  the  creation 
of  a  new  aircraft  and  flight  path.  Similarly,  intercept  control  directives  from  the 
CE  would  be  relayed  to  ADSIMl  resulting  in  modifications  to  the  existing  flight 
paths  of  the  blue  intercept  aircraft.  The  conversion  between  the  internal  database 
of  ADSIMl  and  the  ADFORM-based  textual  messages  is  achieved  through  the 
use  of  mapping  rules  in  a  similar  manner  to  that  employed  with  the  PN  agents. 
Tassel  tying  also  features  for  peripheral  units. 
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5.5  Employing  a  CSS  for  the  human  player 

Peripheral  units  may  be  employed  as  CSS  by  human  players  to  assist  their 
decision  making.  A  second  copy  of  ADSIM  (ADSIM2)  might  be  used  in  such  a 
role  in  this  example,  as  shown  in  Figure  9.  In  this  case,  ADSIM2  would  be  used 
to  display  the  perceived  air  picture,  ie  the  RAP  as  used  by  the  TAOC  node.  This 
would  be  achieved  by  making  use  of  the  ADSIM  PUI  discussed  earlier  but  in  an 
input  mode  only.  That  is,  the  RAP  messages  received  by  the  TAOC  node  would 
be  fed  to  ADSIM2  such  that  any  latency  and  inaccuracies  injected  by  the 
surveillance  and  C3I  system  are  reflected  in  the  display  presented  to  the  human 
player.  Hence  the  resultant  display  might  differ  significantly  from  the  true 
picture  of  ADSIMI. 

5.6  Defining  the  initial  scenario 

The  scenario  generation  facilities  of  the  DICE  simulation  result  in  a  collection  of 
independent  stimuli  that  are  scheduled  at  initialisation.  Ideally,  the  artificial 
agents  should  be  general  rules  of  behaviour  that  get  conveyed  their  irutial  states 
prior  to  runtime.  For  this  example,  stimuli  would  include  messages  that  specify 
the  initial  number  and  state  of  aircraft  on  the  ground  and  in  the  air  to  the  SQN 
and  TAOC  as  well  as  any  information  that  conveys  initial  tasking  to  such  entities 
as  the  CE. 

The  ADSIM  PUI  has  been  designed  such  that  ADSIM  can  be  slaved  to  DICE 
stimuli.  This  permits  the  specification  at  initialisation  of  aircraft  flight  paths  and 
sensor  status  that  are  considered  to  apply  at  zero  simulation  time.  A  different  set 
of  stimuli  would  apply  to  ADSIMI  than  to  ADSIM2. 

5.7  Analysis  opportunities 

Simulation  of  the  above  example  involves  emulation  of  iaformation  flow  within 
the  overall  system,  activation  of  the  rules  of  the  artificial  agents  and  actions  by 
the  human  player.  With  the  inclusion  of  a  human  player,  it  is  more  appropriate 
for  the  simulation  to  execute  in  real-time. 

The  general  design  and  data  recording  features  of  the  DICE  simulation  provide 
a  number  of  analysis  opportunities  as  discussed  in  Section  4.4.  The  following  are 
examples  for  the  case  shown  in  Figures  4  to  9. 

•  A  series  of  stimuli-to-response  observations  could  be  made  for  individual 
nodes  such  as  the  TAOC,  SQN  or  CE. 

•  The  military  objective  in  this  example  is  to  intercept  red  aircraft  before 
significant  reconnaissance  has  been  achieved.  The  timeliness  and  quality  of 
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the  information  flow  and  decision  making  within  the  C3I  system  will 
contribute  to  the  extent  to  which  this  objective  is  satisfied.  Post-simulation 
interrogation  of  the  database  or  suitable  measures  computed  during 
runtime  could  be  used  to  make  judgements  about  this  contribution. 

•  ADSIMl  and  ADS1M2  respectively  display  and  hold  data  on  the  actual 
and  perceived  air  pictures.  In  addition,  the  data  that  drives  these  models  is 
captured  m  both  the  logged  inter-node  message  traffic  and  the  record  of 
activities  internal  to  the  artificial  agents.  The  capability  to  compare  the  two 
pictures  therefore  exists  and  is  another  means  of  judging  the  timeliness 
and  quality  of  the  system  under  study. 

•  Critical  path  and  general  parameter  sensitivity  techniques  could  be 
employed  to  inspect  the  sensitivity  of  outcomes  to  variations  within  the 
C3I  system.  For  example,  the  effect  of  varying  the  RAP  update  rate 
between  the  RCC  and  the  TAOC  could  be  investigated.  It  may  be 
necessary  to  replace  the  human  player  with  an  artificial  agent  in  order  to 
conduct  such  processes. 


6.  Future  Research  and  Development 

A  follow-on  task  is  being  addressed  which  has  the  following  main  emphases: 

•  The  provision  of  simulation  technology  to  the  Defence  organisation; 

•  Further  development  or  acquisition  of  tools  for  C31  analysis; 

•  Applications  to  Defence  studies; 

•  Interfacing  simulation  with  operational  C3I  systems;  and 

•  General  measure  of  merit  and  analysis  R&D. 

Development  of  the  DICE  simulation  and  other  quantitative  analysis  tools  will 
continue  within  this  task.  It  is  particularly  important  that  future  development  be 
driven  by  the  lessons  learned  from  application  of  the  simulation  to  Defence 
projects  and  studies.  Some  of  the  areas  to  be  addressed  are  discussed  below. 

The  current  scenario  generation  capability  is  adequate  but  limited  and  will 
need  enhancing  through  increased  robustness  and  visualisation  tools  that 
facilitate  and  extend  useability.  This  is  particularly  important  in  order  to  extend 
the  user  base  of  the  simulation  to  include  military  personnel,  for  example. 
Enhancements  might  include  the  integration  of  some  Order  of  Battle  (ORB AT) 
tool  for  the  specification,  maintenance  and  interrogation  of  blue  and  red  forces. 
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Map  displays  would  be  particularly  powerful  in  the  front  end  of  the  simulation, 
particularly  in  the  specification  of  the  initial  position,  state  and  intentions  of 
entities  involved  in  the  simulation.  Such  displays  could  also  be  employed  as 
useful  run-time  display  facilities. 

The  field  of  artificial  intelligence  needs  to  be  researched  further  in  search  of 
techniques  for  increasing  the  artificial  agent  abilities  to  deal  with  uncertain  or 
incomplete  information,  explain  their  actions  and  acquire  knowledge  through 
learning  and  observation  of  human  interaction[17].  Any  new  techniques  will  be 
judged  against  any  opportunities  to  extend  the  current  PN  approach. 

Optimisation  expertise  has  been  applied  to  the  core  DICE  simulation  database 
in  order  to  improve  performance.  The  findings  of  this  activity,  as  well  as  the 
results  of  ongoing  effort  to  continually  improve  performance,  will  be 
implemented  as  part  of  future  development. 

Full  compliance  with  DIS  protocols  is  important  to  the  DICE  simulation  since  it 
opens  avenues  for  longer-term  interoperability  with  remotely  located  peripheral 
units  such  as  battle  simulations  and  human  player  facilities.  This  will  necessitate 
monitoring  developments  in  this  field  and  assessing  the  extent  to  which  C3I 
information  exchange  can  be  satisfied  by  the  protocols. 

Part  of  the  simulation  implementation  facility  involves  specification  of  how  the 
multiple  processes  that  typify  the  simulation  should  be  distributed  across 
available  processors.  A  capability,  based  on  predicting  data  latency  and  hence 
simulation  performance,  to  automate  the  process  of  determining  the  best 
distribution  is  desired. 


7.  Conclusion 

A  general-purpose  suite  of  tools  for  the  modelling  and  simulation  of  C3I  systems 
has  been  developed.  The  primary  capability  is  that  of  the  DICE  simulation  which 
has  the  following  key  features[16]: 

•  The  ability  to  graphically  define  the  network  of  nodes  and  links  that  form 
the  central  C3I  system  under  examination. 

•  The  ability  to  represent  communication  over  network  links  through 
stochastic  or  deterministic  time  delays. 

•  The  ability  to  specify  a  scenario  under  which  the  C3I  network  will  be 
exercised. 


28 


DSTO-TR-0485 


•  The  ability  to  artificially  represent  and  emulate  over  time  the 
functionality  (input,  output  and  internal  activities)  of  network  nodes 
through  the  use  of  artificial  agents.  Such  agents  can  currently  consist  of 
Petri  net  simulations  and  simple  alternatives  such  as  look-up  tables. 

•  The  ability  to  assign  human  players  to  represent  the  actions  of  network 
nodes.  A  standard  language  is  needed  for  communication  between 
human  players  and  artificial  agents;  ADF  and  DlCE-specific  ADFORM 
messages  are  used.  A  variety  of  ADFORM-related  software  has  been 
developed  including  a  GUI  facility  permitting  human  players  to  receive, 
create  and  submit  ADFORM  messages. 

•  The  ability  to  define  appropriate  MOM  to  be  used  in  a  particular  study 
and  to  develop  artificial  agents  for  the  computation  of  those  measures 
during  run  time.  The  ability  to  specify  mission  requirements  for  each 
measure. 

•  Simulation  controller  facilities  for  run-time  monitoring  and  control. 

•  A  simulation  kernel  that  allows  interoperation  of  autonomous  artificial 
agents,  human  player  facilities,  controller  facilities  and  PUI  for  interfacing 
to  battle  simulations  and  CSS,  for  example.  A  single  and  multiple 
execution  capability  exists  as  well  as  flexible  execution  rate. 

•  A  core  relational  database  architecture. 

•  Post-simulation  analysis  facilities  allowing  inspection  of  single  and 
multiple  simulation  execution  data.  Features  include  the  inspection  of 
information  flows  and  general  effectiveness  analysis  through  comparison 
of  MOM  values  against  mission  requirements. 

•  A  PUI  that  allows  interoperation  of  the  DICE  simulation  with  an  in-house 
developed  air  defence  simulation  ADS1M[19]. 

•  A  partially-developed  PUI  that  will  lead  to  full  compliance  with  DIS 
protocols.  This  capability  has  been  demonstrated  through  interaction 
with  other  DSTO  DIS-related  systems. 

Non-interactive  simulation,  consisting  of  a  collection  of  Petri  net  and  other 
artificial  agents  is  achievable.  This  flexibility  is  important  for  Monte  Carlo  and 
parameter  sensitivity  analyses  which  necessitate  multiple  executions  of  the 
simulation. 

ADSIM  is  the  first  of  many  models  that  need  to  be  readily  available  for 
representation  of  the  overall  tactical  environment  in  a  scenario.  Other  models 
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were  investigated  but  practicalities  did  not  permit  interfacing  to  them.  DIS 
compliance  for  the  DICE  simulation  will  open  up  more  options. 

In  addition  to  the  DICE  simulation  a  Petri  net  explanation  and  analysis 
capability  and  GUI  environment  for  conveying  the  underlying  characteristics  of 
a  Petri  net  agent  to  a  military  domain  expert  was  developed[7,ll]. 

Simulation  is  a  burgeoning  technology  within  the  Defence  community.  In 
particular,  in  the  area  of  C3I  the  interoperation  of  simulated  and  real  systems  is 
regarded  as  a  key  requirement  for  mission  rehearsal  and  other  forms  of  training 
that  also  facilitate  subsequent  analysis.  Also,  the  ready  availabihty  of  C3I  models 
and  simulations  is  critical  to  the  abihty  to  rapidly  respond  to  general  queries  and 
formal  Defence  capability  studies  concerned  with  information  acquisition  and 
general  C3I  system  performance  and  effectiveness  issues. 

This  report  details  developments  to  date  in  the  DICE  simulation  and  associated 
tools  which  are  considered  readily  available  for  use  in  Defence  projects  and 
studies.  A  number  of  activities  are  being  addressed  under  a  new  task  which 
include  interfacing  with  operational  CSS  and  support  to  capability  studies.  The 
lessons  learned  from  applying  the  simulation  will  significantly  influence  further 
development. 


8.  References 

1.  Australian  Government  Publishing  Service,  "Defending  Australia", 
Defence  White  Paper,  Canberra,  1994 

2.  "Australian  Defence  Formatted  Message  System.  Concepts  and 
Management",  Australian  Joint  Service  Publication  (JSP(AS))  820 

3.  Levis,  A.H.,  "Colored  Petri  Net  Model  of  Command  and  Control  Nodes", 
Toward  a  Science  of  Command,  Control,  and  Communications,  Editor 
Carl  Jones,  Progress  in  Astronautics  and  Aeronautics,  Volume  156, 
pp.181-192 

4.  Institute  for  Simulation  and  Training,  University  of  Central  Florida,  Proc. 
4th  CGF&BR  Conference,  IST-TR-94-12, 4-6  May  1994 

5.  Institute  for  Simulation  and  Training,  University  of  Central  Florida,  Proc. 
5th  CGF&BR  Conference,  IST-TR-95-04,  9-11  May  1995 

6.  Bowden,  F.D.J.  (1996),  "Petri  Nets  and  their  Application  to  Command 
and  Control  Systems",  DSTO  Technical  Report,  DSTO-TR-0462, 
December  1996 


30 


DSTO-TR-0485 


7.  Davies,M.,  Bowden,F.D.J.,  DunnJ.M.,  "An  Explanation  and  Analysis 
Capability  for  Extended  Petri  Nets",  DSTO  Technical  Report, 
DSTO-TR-0461,  December  1996 

8.  Bowden,F.D.J.,  Davies,M.,  Dunn,J.M.,  "Representing  Role-based  Agents 
using  Coloured  Petri  Nets",  Proc.  5th  Conf.  Computer  Generated  Forces  and 
Behavioral  Representation,  Orlando,  Florida,  ,  Pub.  by  Institute  for 
Simulation  and  Training,  Florida,  May  9-11  1995 

9.  Miller,D.C.,  'Interoperability  Issues  For  Distributed  Interactive 
Simulation',  Proc.  Summer  Computer  Simulation  Conf.,  1992,  pplOlS- 
1018 

10.  Computer  Associates  International,  Inc.  (1995),  "CA-OpenIngres.  System 
Reference  Guide",  Islandia,  NY 

11.  Dunn,  J.M.,  Davies,  M.  (1996),  "Extended  Petri  Net  Explanation  and 
Analysis  Capability  -  Software  Description",  DSTO  General  Document, 
DSTO-GD-0104,  September  1996 

12.  Phillips,F.G.,  "Air  Defence  Capabilities  Model:  A  Feasibility  Study", 
DSTO  Research  Report,  ERL-0835-RR,  September  1994 

13.  Bouthonnier,V.,  Levis,A.H.,  "Effectiveness  Analysis  of  C3  Systems",  IEEE 
Trans,  on  Systems,  Man,  and  Cybernetics,  Vol.SMC-14,  No.l,  Jan/Feb 
1984,  pp48-54 

14.  Cothier,P.H.,  Levis,A.Fl.,  "Timeliness  and  Measures  of  Effectiveness  in 
Command  and  Control",  Information  Technology  for  Command  and 
Control,  IEEE  Press,  Eds  S.J.  Andriole  and  S.M.  Halpin,  1991,  pp528-536 

15.  Gabrisch,C.,  Schar,T.R.,  Davies,M.,  "ADFORM  Aspects  of  the  DICE 
Simulation",  DSTO  Technical  Report,  DSTO-TR-0484,  January  1997 

16.  Davies,M.,  Gabrisch,C.,  Dunn,J.M.,  Bowden,F.D.J.,  Haydon,N.A., 
Schar,T.R.,  "The  DICE  Simulation;  Technical  Description",  DSTO 
Technical  Report,  to  be  published 

17.  Davies,M.,  "Future  Command  and  Control  Agents  for  the  DICE 
Simulation",  Divisional  Discussion  Paper,  DSTO-DDP-0025,  November 
1995 

18.  Moore,  K.E.,  Brennan,  J.E.,  Alpha/Sim  Simulation  Software  Tutorial, 
Proc.  1995  Winter  Simulation  Conf.,  3-6  December  1995,  pp387-394 


31 


DSTO-TR-0485 


19.  Haydon,N.A.,  "Establishing  An  Interface  To  A  DOS-Based  Air-Picture 
Simulation  Via  A  Local  Area  Network",  DSTO  General  Document, 
DSTO-GD-0117,  November  1996 

20.  Special  issue  on  Distributed  Interactive  Simulation,  Proc.  IEEE,  Vol.83, 
No. 8,  August  1995 


32 


DSTO-TR-0485 


Figure  1  Functional  diagram  for  DICE  simulation  environment 
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Figure  4  Air  defence  example  application:  overall  system 
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Figure  5  Air  defence  example  application:  C3I  system 


Figure  6  Air  defence  example  application:  human  player  allocation 
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Figure  7  Air  defence  example  application:  Petri  net  agents 


Figure  8  Air  defence  example  application:  peripheral  units  (ADSIMl) 
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Figure  9  Air  defence  example  application:  peripheral  units  (ADSIM2) 
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